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REMARKS 

Claims 1-12 are pending in the Application. Claim 1 has been amended at 
lines 4-5 by changing "context service that allows" to "context service supporting 
one or a plurality of synchronous query and asynchronous callback context 
functions, which allows." The same change has been made to Claim 7, lines 4-5. 
Support for such amendment may be found in the Specification at page 8, 
lines 20-21. 

Claims 1-12 stand rejected under 35 U.S.C. § 102(e) as being anticipated 
by U.S. Patent No. 6,807,423 to Armstrong et al. Applicants traverse as discussed 
below. 

The Claimed Invention 

The term "workflow" refers to the automatic routing of documents to users 
responsible for working on them. (See, e.g., the TechEncyclopedia at 
TechWeb.com) As discussed in the Specification, a workflow management 
system includes a workflow engine that carries out automatic scheduling and 
activation of component tasks according to defined business process, while also 
providing formalisms through which business processes are defined. Prior art 
workflow systems are based on the desktop computing paradigm and employ a 
workspace metaphor to present tasks that are to be claimed and performed by 
human participants. Such tasks differ from tasks that are performed by software 
agents and are referred to as staff activities. (Specification, page 2, lines 16-23) 

Prior art approaches have a number of disadvantages, including: (i) users 
are constrained to the desktop computing environment and do not have access to 
business processes when they are away from their desktop; (ii) a user is burdened 
to periodically inspect his or her workspace to check out pending staff activities; 
and (iii) prior art approaches allow for indirect and asynchronous communication, 
but do not allow for direct and synchronous exchanges among human participants, 
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which is very common in business environments. (Specification, page 3, 
lines 7-15) 

Addressing these disadvantages, the claimed invention provides a system 
for pervasive enablement of business processes in which a workflow engine 
executing a business process model has access to a context service to allow 
context-aware applications to obtain user context information. An interaction 
controller, acting as a proxy for human participants in a workflow, determines an 
appropriate collaboration modality for a human participant, and one or more 
modality adapters encapsulate details of communicating with a specific 
collaboration modality to receive a task from the interaction controller and deliver 
the task in a modality-specific format. (Specification, page 5) 

As shown in Figure 1, an interaction controller 1040 interfaces with a 
workflow engine 1030 and a context service 1050. The workflow engine 1030 
executes the business process based on business process models 1010 and engages 
human partners through software agents 1 100 and invoking software 
applications 1 020 by dispatching various tasks to them. Acting as a proxy for all 
human participants in a workflow, the interaction controller 1040 receives 
specification of individual staff activities from the workflow engine 1030 and 
forwards the engine responses from human partners back to the workflow 
engine 1030. A staff activity specification contains information about the human 
partner instance intended to carry out the activity and the relevant messages. Upon 
receiving a staff activity specification, the interaction controller 1040 obtains 
context information of the partner instance from the context service 1050 and 
determines an appropriate collaboration modality for the partner instance. It uses 
an address book 1090 to look up the modality-specific address (e.g., telephone 
number, email address, instant messaging identifier) based on the user name. It 
then establishes communication with the corresponding modality adapters (e.g., 
instant messaging adapter 1060, short messaging service adapter 1070, or email 
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adapter 1080) and supplies it with all the information regarding the staff activity. 
(Specification, page 7, lines 8-27) 

Rejection of Claims 1-12 Under 35 U.S.C. § 102fe) 
Claims 1-12 stand rejected under 35 U.S.C. § 102(e) as being anticipated 
by the instant messaging system taught by Armstrong et al. Applicants traverse as 
discussed below. 

Independent Claims 1 and 7 
The Examiner incorrectly determined that Armstrong et al. anticipate the 
features of independent Claims 1 and 7, from which the other claims depend. To 
begin, Armstrong et al. do not anticipate "a workflow engine that executes a 
business process model" (Claim 1, line 3; Claim 7, line 3), because the disclosure 
of Armstrong et al. does not teach a "business process," which is defined in the 
Specification of the claimed invention: 

A business process is "a procedure where documents, 
information or tasks are passed between participants according to 
defined sets of rules to achieve or contribute to an overall business 
goal". Participants of a business process may be human beings, 
Web services or other software agents. In particular, human beings 
form a very important part of many business processes. A great 
number of large-scale as well as small-scale business processes 
like product planning, software design, service after sales, travel 
request approval and candidate evaluation require the engagement 
of human participants. 
(Specification at 2) Even though Armstrong et al. make a brief, passing reference 
to the use of their invention in a workflow context (Armstrong et al., column 8, 
line 66 through column 9, line 1, relied on in the Office Action at 3), they do not 
anticipate the "workflow engine that executes a business process model" of 
Claims 1 and 7. Similarly, even though Armstrong et al. teach the use of "rules 
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about who may contact the watched party," (Armstrong et al., column 4, lines 7-8, 
relied on in the Office Action at 3), Armstrong et al. do not teach the use of their 
invention in connection with "a procedure where documents, information or tasks 
are passed between participants according to defined sets of rules to achieve or 
contribute to an overall business goal." (Specification at 2, definition of "business 
process") Armstrong et al. do not anticipate application to a "business process," 
as that term is defined in the Specification. 

In addition, Armstrong et al. do not anticipate "a context service 
supporting one or a plurality of synchronous query and asynchronous callback 
context functions, which allows context-aware applications to obtain user context 
information." (Claim 1, lines 4-6; see also Claim 7, lines 4-6) That is, in part, 
because the disclosure of Armstrong et al. does not teach "context- aware" 
applications, as that term is known in the art. {See, e.g., Specification at 1) and, in 
part, because the disclosure of Armstrong et al does not teach a "context service" 
(Claim 1, line 4; Claim 7, line 4), which is defined in the Specification as 
allowing] context-aware applications to obtain user context 
information without having to worry about the details of context 
derivation and context management. It supports both synchronous 
query and asynchronous callback context functions , and allows for 
easy incorporation of new types of context data into the Context 
Service. 

(Specification at 8, lines 18-22) (emphasis added) By contrast, synchronicity of 
communication is integral to the instant messaging system taught by Armstrong et 
al, where the availability of a party is "watched" at all times. (Armstrong et al, 
column 3, lines 47-65; column 4, lines 6-10; column 5, lines 1-9; column 6, 
lines 7-13 and 48-58; column 9, lines 64-67; column 10, lines 29-31; column 11, 
lines 53-62; and column 12, lines 53-62) (are relied on in the Office Action at 3, 
4, and 5) Where the watching step taught by Armstrong involves synchronous 
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monitoring of users, separate steps are provided in Claims 1 and 7 for 
synchronously or asynchronously (Claim 1, lines 4-5; Claim 7, lines 4-5): 
(a) obtaining context information from a context service (Claim 1, lines 12-14; 
Claim 7, lines 10-12); and (b) communicating with a user (Claim 1, lines 15-17; 
Claim 7, lines 13-16). Thus, according to Armstrong et al., a "deferred message" 
does not provide "asynchronous callback context functions" (Claim 1, line 5; 
Claim 7, line 5) but instead refers to "a message that is delivered to the other 
participant(s) only after explicit action on their part, e.g. e-mail and voice-mail." 
(Armstrong et al., column 12, lines 57-59) 

Furthermore, Armstrong et al. do not anticipate "an interaction controller 
that acts as a proxy for one or more human participants in a workflow." (Claim 1, 
lines 7-8; Claim 7, lines 8-9) This is, in part, because Armstrong does not teach a 
the workflow engine executing a business process model , as discussed above. 
Reference to the workflow engine requirement is integral to the interaction 
controller requirement , because Claims 1 and 7 require that an interaction 
controller be able to do the following: 

receivef] specification of individual staff 
activities from the workflow engine , and 

upon receiving a staff activity specification, 

obtain[] context information of a partner 
instance from the context service to determine an appropriate 
collaboration modality for the partner instance, and 

forward[] the engine responses from 
human partners back to the workflow engine, thereby handling 
individual interactions with human participants. 
(Claim 1, lines 9-17; cf. Claim 7, lines 7-12) 

Armstrong et al. do not anticipate the requirement of Claims 1 and 7 to 
receive a task from the interaction controller and deliver it in the proper format: 



YOR920040076US1 



-10- 



one or more modality adapters that encapsulate details 
of communicating with a specific collaboration modality to 
receive a task from the interaction controller and deliver the 
task to said partner instance in a modality-specific format. 
(Claim 1, lines 18-21; cf. Claim 7, lines 13-17) 

Dependent Claims 

The rejection of Claims 2-6 and 8-12 is traversed on the grounds that these 
claims are dependent from allowable base claims and should, therefore, be 
allowed. In addition, with regard to Claims 3 and 1 1, the Examiner is incorrect to 
conclude (Office Action at 4, 5) that Armstrong et al. teach "wherein said 
dynamic context information includes a human participant's . . . activity 
(Claim 3, lines 1-3; Claim 11, lines 1-3) Armstrong et al. do not teach inclusion 
of information about what a user is doing. 

Conclusion 

In view of the foregoing, it is respectfully requested that the application be 
reconsidered, that Claims 1-12 be allowed, and that the application be passed to 
issue. 

Should the Examiner find the application to be other than in condition for 
allowance, the Examiner is requested to contact the undersigned at the local 
telephone number listed below to discuss any other changes deemed necessary in 
a telephonic or personal interview. 
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A provisional petition is hereby made for any extension of time necessary 
for the continued pendency during the life of this application. Please charge any 
fees for such provisional petition and any deficiencies in fees and credit any 
overpayment of fees to Deposit Account 50-0510 (IBM-Yorktown). 
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